1. Field of the Art
Generally, the present application relates to methods, systems, and devices for financial data processing. Specifically, automatic refreshing of back-end authorizations of credit card and other payment transactions by payment service providers is presented.
2. Discussion of the Related Art
Accepting credit card, debit card, prepaid card, and other payment cards is a given for many retail merchants. For online merchants, accepting PayPal® payments, Google Checkout™ payments, and other alternate electronic payment types in addition to traditional credit card payments is becoming more common. Interfacing with the plethora of payment brands that customers expect to be available for payment transactions can be daunting, especially given the regulatory burden of financial regulations, industry standards, and security considerations.
Differing government regulations in different countries, as well as among card associations, presents much of the burden. Merchants who sell and ship goods to consumers in various countries are, of course, expected to comply with all such regulations. The rise of Internet commerce has all but eliminated barriers to consumers finding desired products, and international shipping has enabled merchants to deliver their products to those consumers. However, the exposure to so many differing markets, and the associated burdens, can be especially difficult for small merchants.
Some merchants contract with third-party payment service providers in order to facilitate interfacing with the different types of payment networks. CyberSource of Mountain View, Calif., is one such third party payment service provider.
Third-party payment service providers not only take care of maintaining interfaces between a contracting merchant and payment networks, they also offer other services such as risk management, hosted order pages (e.g., redirected online checkout web pages), and silent order posts (e.g., secure fields for a merchant's online checkout web page). These services are in addition to servicing the typical day-to-day payment transactions of merchants.
In a typical payment transaction, a merchant sends an authorization request for a consumer's payment to the third-party payment service provider, and the third-party payment service provider forwards the authorization request to the proper entity. This entity often is one of many vendors with which the third-party payment service contracts. The entity then obtains an approval for the authorization request—an “authorization”—from the customer's bank through an acquirer or through a card association. The authorization confirms that the customer indeed has money (or credit) in his or her account to pay for the transaction and also locks down or otherwise reserves the money (or credit) in the account.
For example, a merchant sends an authorization request for a customer's credit card payment transaction to CyberSource. CyberSource sends the request to a payment processor, such as Atos Worldline of France. Atos sends the request to a bank (i.e., the acquirer). The bank then obtains an authorization for the request through a card association's network, such as VisaNet™, from the customer's bank that issued the credit card (i.e., the issuer) to the consumer.
In a brick-and-mortar retail store, authorization and capture often occurs in real-time, or synchronously, as the customer waits at the register. For an online store, the time between authorization and capture can be delayed. However, the authorization portion is contemporaneous with checkout so that approval occurs and an order email may be sent before the customer leaves the merchant's web site.
Later at the end of the day, or when the product has shipped, the merchant sends a settlement request to the payment service provider in order to “capture” the funds. That is, a request is made to actually initiate the transfer of the previously authorized and reserved money (or credit) from the customer's account to the merchant's bank account.
This non-real-time, asynchronous request is often bundled with other settlement requests in a “batch file.” A batch file need not be in a file per se; there are other methods of sending this information. For example, a database may be sent instead of a file, or the settlement request can be sent via messaging.
For example, the acquirer may send a batch file at 8:00 pm each evening in order to collect money for its merchants. The bank's batch files can be extremely large due to the ubiquity of the bank's services and global reach.
In some cases, a long time may elapse between authorization and when the product ships. This can be especially true for orders in which customization must be performed on the product, which may take several days or weeks. This poses a problem because transactions need to be settled within a reasonable amount of time after authorization.
Some payment processors allow a delay of around 5-7 days between when an authorization request is authorized and a capture/settlement request is sent. If a capture request occurs after the 5-7 days, the money (or credit) may no longer be reserved in the customer's account. Any such locked down funds are released for other uses by the customer. Obtaining a new authorization for the same transaction can be a burdensome, manual process because of the many layers of bureaucracy, accounting, and fraud prevention that occur in the background.
There is a need in the art for more efficient payment transaction interfacing.